Due to the tremendous success of the Internet, it has become a challenging task to make use of the Internet Protocol (IP) over all kinds of links. However, this is especially difficult for narrow band links such as cellular links, since the headers of IP protocol packets in general are rather large compared to the data (payload). For example, when ordinary speech data is transported by the protocols used for Voice-over-IP (VoIP), the header often represents as much as 70% of the packet, which results in a most inefficient link usage.
Header compression refers to techniques for minimizing the necessary bandwidth for information carried in headers on a per-hop basis over point-to-point links. There are several header compression protocols, including RFC 1144 [1], RFC 2507 [2] and RFC 2508 [3]. The principles of header compression take advantage of the fact that some header fields are not changing within a flow, or alternatively change with small or predictable values. These characteristics are used by the header compression schemes, which send static information only initially, while changing fields are sent with their absolute values or as differences from packet to packet. Completely random information has to be sent without any compression at all.
Header compression is an important component to make VoIP over Wireless (VoIPoW) an economically feasible alternative to circuit switched voice, and for this purpose solutions for Robust Header Compression (ROHC) have been developed. ROHC, as defined in RFC 3095 [4], is an extensible framework for which profiles for compression of various protocols can be defined. For VoIP, the application data is transported end-to-end within an IP/User Datagram Protocol (UDP)/Real-time Transport Protocol (RTP) stream. Header compression of IP/UDP/RTP is defined by the ROHC profile 0x0001 (ROHC RTP) and is applicable for VoIP services among others. The ROHC RTP header compression scheme has been designed to efficiently compress headers over an arbitrary link layer. Most functionality is handled by the ROHC RTP scheme itself and, except for negotiation, only framing and error detection need to be provided by the link layer.
ROHC has three different modes of operation, which, for a specific context, control the actions and the logic to perform as well as the packet types to use during different states of the header compression operation. Allowed packet types and formats may vary from one mode to another. The Unidirectional mode (U-mode) is used at the beginning of any ROHC compression before transition to another mode may occur. The Bidirectional Optimistic mode (O-mode) aims to maximize the compression efficiency and is associated with sparse usage of the feedback channel. The Bidirectional Reliable mode (R-mode) aims to maximize robustness against loss and context damage propagation.
When in U-mode, packets are sent from compressor to decompressor only; this mode is thus usable over links where a return path from decompressor to compressor is either not desired or not available, and periodical refreshes are used in this mode. The 0-mode is similar to the U-mode with the difference that a feedback channel is used to send error recovery requests and (optionally) acknowledgements of significant context updates from the decompressor to compressor. The U-mode and the 0-mode are often together referred to as the U/0-mode due to the very similar nature thereof. The R-mode is significantly different from the two other modes, mainly by a more extensive usage of the feedback channel and a stricter logic for performing context updates. The R-Mode also uses a few different packet types only understood and useful in this mode.
Each mode of operation has different properties in terms of compression efficiency, robustness and processing complexity. ROHC does not specify how and when the respective modes should be used (except that ROHC compression must always start in U-mode), whereby the logic for mode transitions becomes an implementation issue. Mode transitions may only be initiated by the decompressor, and according to the current specification for Robust Header Compression (RFC3095) every ROHC implementation must support all modes of operation.
The above characteristics and requirements of prior-art header compression schemes are associated with a number of drawbacks.
Header compression vendors are likely to optimize their compressor implementations for specific modes of operation, e.g. in order to minimize the memory requirements or the required processing power. However, there is no guarantee that a particular implementation will actually be used in its preferred mode. Instead it may be forced into sub-optimal operation, resulting in reduced compression efficiency and link performance.
Another problem is that a lot of functionality is needed for a ROHC implementation to support all compression modes. Considerable implementation, validation and testing actions have to be performed, which in turn implies relatively long implementation times and high implementation costs. All modes may not necessarily be useful in a specific environment. Furthermore, in order to minimize the program footprint and/or the time required to build an interoperable ROHC algorithm implementation, it would sometimes be desirable to only support the mode(s) consistent with the deployment strategy of a particular implementer.
Accordingly, the header compression of conventional telecommunication systems is far from satisfactory and there is a considerable need for an improved header compression method, in particular one that offers compression mode flexibility.